Maintaining server persistency in web-based environment is a well known requirement for every web-based property that would like to maintain clients' sessions' context for environments with multiple identical web-servers, as the underline HTTP protocol is stateless by its nature. This mechanism is usually implemented by Application Delivery Controller (ADC) internal or external to the servers. One of the main duties of ADC is to balance the load between multiple, function-identical servers. With ADC, these servers look like a single high-powered computing resource that allows many clients to access it simultaneously, and then balances the load between these function-identical web-servers. Few existing load-balancing mechanisms are known in the art and will not be described by this paper. When an ADC is configured to work with persistency, it guarantees that client's consecutive requests which belong to the same session will follow the same destination server as the first session request. The following main techniques are available today for achieving this functionality: (i) maintaining session persistency by source IP address, (ii) maintaining session persistency by HTTP session cookie, (iii) Maintaining session persistency by adding session identifier to URI part of the URL; and (IV) maintaining session persistency using a URL identifier.
Maintaining session persistency by source IP address—in this case the ADC looks for the source IP address of the client (the source IP address appears in every TCP/IP packet that carries HTTP traffic) and forwards all the requests which are coming from the same IP address to the same destination web-server. This method is poorly working when many users are accessing the same web-based application through Mega-Proxy server(s) (e.g. AOL service provider users). Mega-Proxy/proxy server replaces the client source IP addresses with its own addresses pool, thus forcing the ADC to forward all the clients to the same web-server, thus creating unbalanced environment.
Maintaining session persistency by HTTP session cookie—cookie is a well-know mechanism for maintaining session states by the web-server. When a web-server sets a session cookie in a response to a client request, the client is forced (by his/her browser software) to send this cookie header for every consecutive request to the same domain/site during that session. An ADC which sits between the server and the client can trace/modify/add a dedicated cookie header on the server response, in-order to signal itself to which server to forward the next requests from that particular client on the way back. Although this method is commonly used, it doesn't solve the issue of persistency when cookie mechanism is disabled by the client. A description of this method can be found in U.S. Pat. No. 6,473,802 which is incorporated herein by reference.
Maintaining session persistency by adding a session identifier to URI part of URL—when cookie isn't supported by the client, the web-server (by adjusting its code) can add session identifier to the URI part of the URL in every HTML response it sends. The ADC then traces the session identifier on the server response and saves this information in its internal memory together with the identifier of the server from which the response has come. Upon receiving the next request from the client, the ADC matches the URL identifier with those which are stored in its memory and forwards the request to the designated server which appears in its memory. This method will only work when the server code is adjusted to add URL identifier for every URL in the HTML response, and it significantly increases the processing overhead of the web-server. The method of maintaining session persistency without client supported cookie is described by U.S. Pat. No. 7,296,076 of Portolani which is incorporated herein by reference.
Maintaining session persistency using a URL identifier—this method is a combination of methods 2 and 3 above, whether or not the client supports cookie, the persistency is achieved by adding server identifier to every URL in the HTML server response. On the first client's request the ADC selects one server out of plurality of servers according to its load-balancing algorithm, and then later adds this server identifier to all the URLs which appear on the server's HTML response. The next coming requests from this particular client will include the server identifier, as part of the URL, to which the request should be forwarded to; the ADC then deletes this identifier, to prevent unexpected server behavior, and forwards the request according to the deleted server identifier value. An example of how to maintain persistency using URL identifier can be found in US patent application publication serial number 2003/0163586 of Schnetzler.
Method 4 above, does not address the issue of persistency in modern web-based environments where server's responses include browser code program, such as Java Script, Flash, Silvertight, AJAX, etc. These browser codes hide the URLs that will be sent by the client's browser program in a non-standard way, e.g. every browser code programmer can select his/her own way of writing the code, making the response URL modification task impossible.